collection

2.2. Consuming time zones

Quite often, applications have a list of time zones stored internally or in a non-standard registry, and when a meeting is created with a time zone, the application will:

  1. Try to match the supplied time zone with its internal representation. This match can be accomplished by using any of these techniques:

    • Have an algorithm pick an internal time zone with the closest corresponding set of rules to the supplied one.

    • Try to match the TZID with its internal counterpart.

  2. If no match can be found the application will do one of these:

    • Return an error.

    • Add the new time zone to its internal time zone list.

At this point, these problems can occur:

2.2.1.

If the application cannot add “unmatchable” time zones to its internal list, even a perfectly valid VTIMEZONE can be rejected.

2.2.1.1.

The meeting could be converted to UTC using the provided time zone, take note that this solution is less than ideal since time zone information is lost.

2.2.2.

If the application has in its internal list a TZID “America/New_York”, and receives a VTIMEZONE with a TZID “America/New_York” with a different definition than its internal one, the server may react unpredictably.

2.2.2.1.

If using a time zone registry the time zone definition of the registry should be the one used.

2.2.2.2.

If using an internal time zone list that can be changed, a versioning of the TZID could be used allowing different versions of the same TZIDs to be kept. This would allow applications to have events using different time zones with the same TZID. Take note however that consuming and preserving all time zones can become quite problematic:

  • Since time zone ids are often shown to users, the time zone list could become quite large and confusing over time.

  • The need to “preserve” the original consumed time zone can also look like a bad idea when a time zone rule changes; meetings that have yet to occur will most likely need to be updated with the new time zone rule.